如何基于OpenShift容器云平台实现微服务改造的分布式应用集成和流程自动化？
1、如何划分流程自动化覆盖范围界限？微服务化的流程全连路图所需自动化的自动化标准工具技术选型？
@魏新宇 红帽资深解决方案架构师：
红帽的流程自动化工具是rhpam，它里面实际上也包括规则引擎的内容。对应的开源社区项目是：drools，jbpm，bpmn等。方案可以提供那种图形化的流程展示和拖拽式生成流程。红帽对比也提供企业级支持。
@王洪涛 红帽资深解决方案架构师：
这次介绍里提到的自动化，其实更多的是业务规则到流程的自动化，只是在paas的这个大话题下，焦点都关注在了devops相关的自动化环节。
自动化主要包括：
比较容易实现的是批量作业自动化、自动巡检。
以及实现难度中等的软件批量分发部署和配置与版本管理自动化。这部分需要结合PaaS平台的若干能力实现，主要就是openshift或者k8s，再加上一些ansible tower的工具，satellite之类。
还有实现起来最复杂的应急故障检查和容灾管理自动化。这还需要加入一些咨询服务。
当然，还有自动化测试等领域。
微服务的流程全链路，主要有些：需求管理Jira，自动化测试selenium，代码扫描,Sonarqube，,CICD jenkins或者TFS，等
2、如何在OpenShift上实现微服务系统发布的流程自动化？是通过jenkins来做CI/CD吗？
@王洪涛 红帽资深解决方案架构师：
没错，现阶段，大多数都是使用的Jenkins。openshift 3和openshift 4也都是内置了Jenkins组件实现。
3、OpenShift的流程自动化如何和现有的ITIL，工单系统对接？
@eximbank 某金融企业 系统架构师：
1，ITIL 及工单更偏重于日常管理流程，Openshift 的流程自动化是偏重于业务-应用服务诞生的流程，所以两者本质上有区别；
2，openshift 流程自动化，是服务编排的自动化过程，涉足的相关负责人是需要 ITIL 流程通知到对应的负责人员，所以期待 Openshift 自动化流程与 ITIL 工单流程相结合，共同服务到业务-应用服务的运营运维；
3，如何对接，就需要梳理和抽象 ITIL 工单流程中要交互的目标元素和Openshift 对象元素，两者粒度的衔接，如果衔接完善，就可以对接，否则就只能通过负责人 ID 来进行衔接，此时的对接，基本上都是人为流程，相对来说集成负责程度增加了。
4，流程自动化和工单流转自动化，是需要自动化流程引擎的，一个服务编排，一个是服务流转，一个是自动化，一个是粒度元素审批和信息交互，有差别，也有交叉。说实话，挺复杂的！
@王洪涛 红帽资深解决方案架构师：
OpenShift平台本身涉及的流程主要在于镜像的构建、版本管理、同步，以及应用的发布、启停。和ITIL的集成工单系统对接，也应该在于这些环节。
实现起来最复杂的是：应急故障检查和容灾管理。最好同时借助于其它工具，比如：通过Ansible Tower + Satellite + ITIL + BPM + 专业服务/其他开源工具实现。
4、OpenShift上DevOps流程中角色、权限、功能的相关问题？
1.OpenShift上DevOps流程是否有角色的概念？比如开发、运维、测试，这些角色在平台上的功能和权限是如何定义的？
2.OpenShiftt上DevOps流程是否支持管理上的审批功能？如果支持，是实现在流水线上的？还是独立的审批流程？
@eximbank 某金融企业 系统架构师：
1，Openshift 是完全有自在的 BRAC 管理体系
2，只要 BRAC 源支持，就可以集成；
3，审批部分是将人为管理流程与CI/CD流水线相结合的集成，就看展现那些流水线粒度信息给审批者了，这个需要集成开发。
@王洪涛 红帽资深解决方案架构师：
1、有。OpenShift本身有角色概念。通过RBAC实现角色授权。
2、支持，流水线上的。
5、使用OpenShift+Fuse对比通过Camel、Servicemix 实现分布式应用集成，有什么不同？
@王洪涛 红帽资深解决方案架构师：
Fuse即是红帽企业版本的Camel。（Fuse的上游社区是Camel）
Fuse的镜像在OpenShift之上实现了无状态调整。已更好的适应云原生。
Fuse的镜像去掉了一些没有必要的组件，以提高安全性和启动快捷性。
Fuse可以更加容易和API管理平台，例如3scale进行对接。
6、为了上OpenShift，传统应用进行无状态化改造的过程中，有哪些特别需要注意的地方或者经验分享？
@eximbank 某金融企业 系统架构师：
梳理传统应用的交互内容数据集，如果是大而全的紧耦合数据集交互，现将梳理和拆分可以微服务化的松耦合分布式数据集，再进行应用改造；
如此这样可以分步骤、分阶段进行改造；完全颠覆性重构，付出的代价估计比较大，投入成本和相应的运维体系、支撑体系、工具链体系都得配套随着业务改造而增加，不仅学习成本高，维护粒度反而增加，为业务运维人员增加不小的工作量。
1，先梳理传统业务应用服务的特点；
2，针对改造中涉及的工具链支撑平台先行建设；
3，转型服务团队技能和运维体系；
4，持续增加技术投入
5，适时借鉴第三方厂商经验和技术赋能，是掌握和改造业务-应用服务的关键要素。
@魏新宇 红帽资深解决方案架构师：
OpenShift既可以支持无状态应用，也可以支持有状态应用（使用statefulset），如redis、mysql等。整体上看，运行的无状态应用会多一些。
已建立了清晰的可自动化的编译及构建流程
应用使用了如Maven、Gradle、Make或Shell等工具实现了构建编译步骤的自动化。这将方便应用在容器平台上实现自动化的编译及构建。
已实现应用配置参数外部化
应用已将配置参数外部化于配置文件或环境变量中，以便于应用容器能适配不同的运行环境。
已提供合理可靠的健康检查接口
容器平台将通过健康检查接口判断容器状态，对应用服务进行状态保持。
已实现状态外部化，实现应用实例无状态化
应用状态信息存储于数据库或缓存等外部系统，应用实例本身实现无状态化。
不涉及底层的操作系统依赖及复杂的网络通信机制
应用以处理业务为主，不强依赖于底层操作系统及组播等网络通信机制以提高可移植性。
部署交付件及运行平台的大小在2GB以内
轻量级的应用便于在大规模集群中快速传输分发，更符合容器敏捷的理念。
启动时间在5分钟以内
过长的启动时间将不能发挥容器敏捷的特性。
7、对于OpenShift，应用内产生的持久化数据，有哪些方案进行存储，同时数据保护这块是怎么做的？
@魏新宇 红帽资深解决方案架构师：
OpenShift在数据中心内部部署的时候，如果是生产环境，如果没有多pod共享一个pv的情况，可以使用Ceph RDB，也能还不错。如果有少量的多pod共享，可以使用CephFS。如果有大量的pod都需要共享pv，那么可以选用企业级的NAS。Ceph通过三副本进行数据保护，企业级NAS则通过自身存储的机制可以实现。
8、传统金融行业，云原生应用比率很低，企业如何基于OpenShift容器云平台做微服务化？微服务架构与传统架构，在产品研发过程，需要提前考虑哪些因素，有无最佳实践？
@魏新宇 红帽资深解决方案架构师：
云原生是一个较大的话题，实际上企业不必为了云原生而云原生。目前看到的实例案例，金融客户大多web类应用，都使用SpringBoot开发，然后通过红帽提供的OopenJDK进行进行容器化，然后运行在OopenShift上。如果要使用SpringCloud治理框架，由于它是代码侵入式的，那么在应用开发过程中，就需要使用使用anotation引入SpringCloud。目前看到的用户，所有SpringCloud框架模块都上齐的不太多，大多是使用SpringBoot，然后引入少量的治理模块，比如Hystrix。从发展角度看，istio是未来微服务的发展方向，因为它没有代码侵入。目前很多客户在测试它，但国内生产环境案例还不多。
9、容器和虚机混合部署的应用，如何进行快速部署？有没有什么好的实践？
@魏新宇 红帽资深解决方案架构师：
OpenShift3.11中，虚拟机和OCP的部署是相对独立的。也就是说，先部署好VM，安装好RHEL，然后再通过Ansible的Playbook来部署OpenShift。在OCP4的部署模式分为IPI和UPI，前者是全自动化部署，VM和OCP可以统一部署。目前4,2支持的IPI包括AWS、红帽OpenStack。IPI是手工部署，需要提前准备好VM，然后部署的时候，是VM中的CoreOS和OCP一起部署（OCP4底层HostOS使用CoreOS）。
OCP中的pod要访问外部网络，是通过NAT的方式，以其所在的OCP node IP出去的。
10、OpenShift 的网络方案是怎么样的？
openshift 的网络方案是怎么样的，是underlay的还是overlay 的，能支持同一集群多种网络方案共存么
@魏新宇 红帽资深解决方案架构师：
OpenShift相关的网络包含两部分：入口流量和内部的SND。入口流量红帽使用容器化的haproxy。SDN方面，OpenShift 3.11默认使用OVS， overlay 的 ；OpenShift也认证过几个第三方的SDN，如Calico，NSX等。OpenShift 4未来的计划是使用OVN。目前OpenShift 4.2的OVN，底层还是调用了OVS， overlay 的。
11、OpenShift相对于开源容器网络解决方案，如Flannel、Calico有哪些优势？针对金融科技行业网络安全区域分级的监管要求，OpenShift的网络解决方案是否可以有效适配多个网络安全区域隔离的场景？
@王洪涛 红帽资深解决方案架构师：
Flannel/Calico，本身也可以作为OpenShift网络解决方案的组成部分。
其中Flannel是coreos公司专门为k8s设计的sdn组件，而coreos公司现在已被redhat收购。
OpenShift的价值在于平台本身已经对这些组件做了安全认证和集成加固。
12、红帽OpenShift容器平台中实现CI/CD与Jenkins有什么优势和特点？
@魏新宇 红帽资深解决方案架构师：
OpenShift3中，实现CI/CD通常会借助于Jenkins来实现Pipeline管理或者CI。OpenShift4.2中的CI/CD已经可以不适用Jenkins了，适用teckton实现pipeline管理。OpenShift上实现CI/CD，推荐的方案是使用teckton。如果在上openshift之前已经使用了jenkins做CI，也可以延续以前的做法。
13、OpenShift的分布式PaaS平台和Knative Serverless在支持kubernetes上有哪些区别？
@王洪涛 红帽资深解决方案架构师：
OpenShift 也是使用的 Knative 以及ISTIO的部分功能来实现 Serverless。
14、随着google和社区在不断优化和降低Kubernetes 的使用门槛和复杂度，OpenShift相比优势又有哪些？
@魏新宇 红帽资深解决方案架构师：
首先，红帽是K8S开源项目的最早发起者，目前也是K8S社区代码第二贡献者。早期的K8S缺乏企业级功能，OppenShift则予以补充。目前K8S的功能基本已经完善。K8S和OpenShift的定位区别在于：前者是容器调度平台，后者是企业级PaaS平台，提供实现DevOps、微服务的能力。每个版本的OpenShift都会包含一个版本的K8S。但OpenShift还提供K8S不具备的功能，比如持久化存储Ceph、应用的SSO、企业级容器化中间件JBoss、Tomcat等。此外，OpenShift具备红帽企业级支持，而K8S则没有。所以，在金融、能源、电信行业，客户生产环境往往选择OpenShift,即使这些客户之前验证过K8S。
更多分享和解答，可点击文末阅读原文，到社区浏览 觉得本文有用，请转发或点击“在看”，让更多同行看到
相关推荐：
基于云原生的敏捷集成和流程自动化
http://www.talkwithtrend.com/Document/detail/tid/430629
红帽云原生runtime助力容器云平台实现CICD
http://www.talkwithtrend.com/Document/detail/tid/430665
欢迎关注社区 "OpenShift"技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/91779
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场